1. Background and Relevant Art
Conventional applications that use a state machine model for processing objects handle the various objects (e.g., client requests) through a number of different, successive processing modules in a processing chain. With a state machine model, each processing module processes the object, and stores some state for the object, as the object passes from one processing module to the next in the processing chain. Some common examples of applications that use a state machine model for processing include web servers and firewalls.
For example, a web server or a firewall application may receive a request (e.g., the aforementioned object) from another client system, such as a request to access services maintained through the web server, or to access services behind the firewall. The web server or firewall application, in turn, may process the request through a first processing module that produces a time stamp on the request, while another, subsequent processing module determines various metrics about the request (e.g., packet size, communication protocol used in transmission, etc.) Upon processing the request, each processing module passes the request through to the next processing module in the processing chain until reaching the last processing module in the chain, and thus a completed set of states for the client request.
In conventional systems, each processing module in the aforementioned example will need to finish processing the request before passing the client request onto the next processing module, and so forth. In some cases, however, finishing the processing request may not be a simple, quick matter. For example, a given processing module may only be able to process the request in the context of one or more conditions. Specifically, the given processing module may have subscribed to various system “events” that need to occur as part of the processing module's processing configuration, and thus before completion for the particular processing module.
For example, as in the above example, a processing module that is adding a time stamp to an incoming request may need to wait for an internal signal from the system that a clock event has been updated, before obtaining the current time. Another processing module might need confirmation from another event that some credentials presented in the client request have been verified. Similarly, another processing module might some confirmation that a list of valid URLs has been updated. With respect to a web server application, there may even be some similarity in the events needed for a security processing module that blocks/reroutes traffic and a URL rewriter processing module that also reroutes traffic. Of course, there can also be a number of different events to which each processing module subscribes, and the number and types of events that can occur in a system can vary widely.
Unfortunately, because each processing module in a particular processing chain can affect or change the received client request, one will also appreciate that there may be instances in which processing by one processing module on a particular client request adversely affects how a subsequent processing module in the processing chain processes the same request. Complicating this is the notion that the ordering of processing modules in a given processing chain for a state machine tends to be arbitrary. One reason for this is that, when a developer is creating a processing module for a particular processing chain, the developer often has difficulty identifying the functions and results of other processing modules in the processing chain.
Typically all that a developer can know about other processing modules in a given processing chain is the name of the processing modules, and, in some cases, the identity of the events to which they subscribe. To obtain more information than this (e.g., how the module processes in view of events), a developer might even run a series of tests to determine how the processing modules process a particular request at certain intervals. This can involve some fairly complex interactions in which the developer initiates processing of a request through a processing chain, and arbitrarily stops processing midway through the processing chain to determine what has happened.
Thus, one will appreciate that it can be difficult to accurately determine how other processing modules, particularly those other than the ones created by a developer, work in a particular processing chain. As a result, and to ensure that a new processing module will work as intended, developers tend to place their newly created processing modules at the beginning of a particular processing chain. As previously mentioned, however, this sort of ordering ultimately results in arbitrary ordering of modules over time, as developers continually place their new processing modules at the head of a given processing chain.
One will appreciate that this sort of arbitrary ordering can have adverse consequences to the efficiency of the web server's processing chain. For example, there may be many processing modules that require few or no events to occur before completing processing of a particular object/request, and these may be at the end of a given processing chain. As a result, processing modules that could or should be processed sooner in a processing chain may not be processed until much later. Similarly, it may be the case that processing modules that need to process the client request in a relatively unmodified state may not be able to process the client request until other processing modules have modified the client request, thus removing important information from the request. As a result, some processing modules farther down the processing chain may only be processing the client request incompletely, or potentially incorrectly.
Accordingly, there are a number of disadvantages with the provisioning and ordering of processing modules using a state machine model that can be addressed.